When parsing a binary fragment, the library attempted to decompress the
patch data before checking the expected size and without specifying any
limit. This allowed a malicious patch to include an "inflate bomb" as a
binary fragment, forcing the library to allocate excessive memory during
parsing.

The BinaryFragment type now stores the raw compressed data at parse time
and provides a separate method to get a reader for the decompressed
data. The reader limits the decompressed size to the declared size in
the fragment. This is an API break, but I expect very few clients
interact with binary fragment data directly.

This fixes the unbounded inflate during parsing and also limits the
memory allocated by the library during an apply to a copy buffer.
However, applying a patch can still write large amounts of data to the
client-provided writer in ways the client can't easily prevent. A future
commit will enforce limits at apply time to fix this.